Status:  U
Message-ID: <8B6921F7BCC5474D8D861D703C86F79D@Shasta>
From: "Stephen H. Fischer" <SFischer1@Mindspring.com>
To: "CoCoList for Color Computer Enthusiasts" <coco@maltedmedia.com>
References: <20110524212513.GA6439@brawl.fslf.org><201105250032.09184.gheskett@wdtv.com><A7EEA425FE814B7CA062FA0D5F10BCFD@Shasta><20110525195346.GC14480@brawl.fslf.org>
	<9B6B5EC6-BC3F-4088-B92E-7A47ABA349BA@ocs.net>
In-Reply-To: <9B6B5EC6-BC3F-4088-B92E-7A47ABA349BA@ocs.net>
Date: Wed, 25 May 2011 15:28:57 -0700
Organization: A. Nani Mouse Inx.
MIME-Version: 1.0
Subject: Re: [Coco] cprep19 __FILE__ fix?
Precedence: list
Reply-To: CoCoList for Color Computer Enthusiasts <coco@maltedmedia.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: coco-bounces@maltedmedia.com
Errors-To: coco-bounces@maltedmedia.com

Hi,

I discovered and downloaded the source for c.comp a few days ago, but I 
cannot find out where it came from now.

It included source for Clib. Both Krieder's and MW versions.

I put it up on my web page:

http://home.mindspring.com/~sfischer1/

I do not see ctime.

Enjoy.

SHF

----- Original Message ----- 
From: "Michael Furman" <n6il@ocs.net>
To: "CoCoList for Color Computer Enthusiasts" <coco@maltedmedia.com>
Sent: Wednesday, May 25, 2011 2:49 PM
Subject: Re: [Coco] cprep19 __FILE__ fix?


>
> On May 25, 2011, at 12:53 PM, Willard Goosey wrote:
>
>> On Tue, May 24, 2011 at 10:12:09PM -0700, Stephen H. Fischer wrote:
>>> The __DATE__ should (must) be changed to return a date in the 2xxx range 
>>> as
>>> it is "Today's" date.
>>
>> OK, easy enough.  But someone who's good at binary patching and/or
>> disassembling things should fix Krieder's ctime() properly.  And that,
>> btw, would not be me.  I'm not very good with 6x09 assembler.
>
>
> Willard, I looked into this a few months ago.  Off the top of my haead:
>
> 1) I have some source for the Krieder C library, but when I assembled it, 
> it was not exactly the same as binary copies floating around.  This 
> reduces my confidence that the resulting clib after hacking will actually 
> work properly, and makes it difficult to generate a patch that will always 
> work.  The date command returns the correct year.
>
> 2) clib's asctime function had some contribution to the problem but the 
> details escape me ATM.
>
> 3) I took a look at Nitros9's date command and it has some Y2Kish stuff 
> there but it's not clear if it works correctly.  The algorithm there 
> seemed a bit convoluted or worked the problem backwards (from my 
> perspective) for some unknown reason (to optimize it? for 8-bit math 
> apparently?).  The comment in date.asm is from Grandpa Gene:
> *   5      1996/09/25  Gene Heskett
> * Made Y2K compliant.
>
> 4) It appears that Nitros9 keeps a 1-byte year, so this is what one would 
> expect F$Time to return.  According to OS9Defs:
> D.Time         equ       .                   System Time
> D.Year         rmb       1
>
> I'll try to fill in the rest of details from my previous investigation of 
> this issue later this evening.
>
> The result was that to fix UUCPBB (Which reported the year as 19111 in 
> some places and 111 in others) I basically changed any occurrence of 
> '19%d', year to '%d', 1900+year.  This was a hack that doesn't address the 
> real lower level problem.
>


--
Coco mailing list
Coco@maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco